1. Field of the Invention
The present invention relates generally to a system providing methods for facilitating development and maintenance of software applications or systems, with particular emphasis on a system and method providing status indication for long-running modal tasks.
2. Description of the Background Art
Before a digital computer may accomplish a desired task, it must receive an appropriate set of instructions. Executed by the computer's microprocessor, these instructions, collectively referred to as a “computer program,” direct the operation of the computer. Expectedly, the computer must understand the instructions which it receives before it may undertake the specified activity.
Owing to their digital nature, computers essentially only understand “machine code,” i.e., the low-level, minute instructions for performing specific tasks—the sequence of ones and zeros that are interpreted as specific instructions by the computer's microprocessor. Since machine language or machine code is the only language computers actually understand, all other programming languages represent ways of structuring human language so that humans can get computers to perform specific tasks.
While it is possible for humans to compose meaningful programs in machine code, practically all software development today employs one or more of the available programming languages. The most widely used programming languages are the “high-level” languages, such as C, Pascal, or more recently Java®. These languages allow data structures and algorithms to be expressed in a style of writing that is easily read and understood by fellow programmers.
A program called a “compiler” translates these instructions into the requisite machine language. In the context of this translation, the program written in the high-level language is called the “source code” or source program. The ultimate output of the compiler is a compiled module such as a compiled C “object module,” which includes instructions for execution ultimately by a target processor, or a compiled Java® class, which includes bytecodes for execution ultimately by a Java® virtual machine. A Java® compiler generates platform-neutral “bytecodes”—an architecturally neutral, intermediate format designed for deploying application code efficiently to multiple platforms.
“Visual” development environments, such as Borland® JBuilder®, are the preferred application development environments for quickly creating production applications. Such environments are characterized by an integrated development environment (IDE) providing a form painter, a property getter/setter manager (“inspector”), a project manager, a tool palette (with objects which the user can drag and drop on forms), an editor, a debugger, and a compiler. In general operation, the user “paints” objects on one or more forms, using the form painter. Attributes and properties of the objects on the forms can be modified using the property manager or inspector. In conjunction with this operation, the user attaches or associates program code with particular objects on the screen (e.g., button object). Typically, code is generated by the IDE in response to user actions in the form painter and the user then manipulates the generated code using the editor. Changes made by the user to code in the editor are reflected in the form painter, and vice versa. After the program code has been developed, the compiler is used to generate binary code (e.g., Java® bytecode) for execution on a machine (e.g., a Java® virtual machine).
Although visual development environments enable applications to be created quickly, problems remain with the development, implementation, operation, and maintenance of production applications. One issue for users of a program or application is the handling of modal tasks by current systems. A modal task is a task that generally suspends user interaction in a program or system until the modal task has completed processing. An example of a modal task is formatting (or reformatting) the hard drive of a computer system. While the hard drive of the computer system is being formatted, the user interface is usually “frozen” and the user is unable to initiate other tasks. In addition, in many cases the user is provided little or no feedback while the modal task is in process, which can be frustrating to the user. The user may not know how long the modal task will take, and in many cases may not be able to cancel or delay running of the modal task once it has been initiated. Accordingly, there is considerable user interest in a solution that provides feedback about the status of such modal tasks and enables the user to cancel the modal task, if desired.
However, displaying a modal progress dialog (or other status indication) while performing a lengthy modal task presents a number of problems for a program or application (e.g., an application written in the Java® programming language) if the task is performing on the event thread. Typically, if both the task and the progress indication (e.g., animation or dialog box presented in the user interface) are running on the same thread, the status will not update properly and the progress indication will not be painted (or repainted) while the modal task is in process. In addition, any user input, such as requests to cancel the modal task, cannot be processed until after the task has been completed, thus invalidating or ignoring the user input.
For instance, in an application written in the Java® language and running in a Java® virtual machine environment, the Java® event thread is generally responsible for watching interaction with a graphical user interface (GUI), refreshing the user interface (UI), and dispatching UI events. The event thread dispatches UI events by periodically examining the system event queue for any UI events such as mouse clicks or keystrokes. Threads execute tasks sequentially and a thread can only perform one task at a time. Thus, when the event thread is being used for executing a lengthy modal task, the user interface cannot be refreshed and events cannot be processed during the duration of the modal task. This effectively renders any sort of modal progress dialog that provides feedback on the status of the lengthy task useless, because the dialog's user interface is managed on the event thread and therefore cannot be refreshed until the modal task has completed. In addition, the user is usually unable to cancel the modal task since any user input will not be processed until after the task has been completed.
Some of these problems may be addressed by running the task on a separate background thread, and incorporating the use of a progress indication dialog on the main event thread. However, this approach may result in decreased performance. For example, in a Java® environment a modal task can generally be processed faster on the Java® event thread than on other threads. However the event thread is also the thread that handles user interface events, so the progress indication is also usually run on the event thread. Accordingly, while it may be possible to execute the lengthy task on a thread other than the event thread, the use of the event thread is desirable in many instances for performance reasons and/or in order to avoid thread synchronization issues.
Accordingly, a solution is required for providing users with an indication of the progress of modal tasks which are running on the event thread of a system. Ideally, the solution should also provide users with the ability to cancel a modal task while it is being processed. The present invention provides a solution for these and other needs.